fix(core): wrap observer-object handlers like functions, and let a wrapped promise settle after teardown - #3829

…rotask

angular#3829's destroyed-injector early return now sits inside the try, so the
finally removes the pending task on that path too. The argument loop is
main's, without the TODO this branch deleted. angular#3829's spec comment about
a 0 ms timer now gives the reason the per-spec counter still holds.

# Conflicts:
#	src/zones.spec.ts
#	src/zones.ts

angular#3829 wraps a handler passed as an observer object, such as { next, error }, the way it wraps a function, so the injection context reaches both forms.

Refs angular#3828

angular#3829 set onConfigUpdate to blockUntilFirst: false in tools/build.ts,
because its observer runs only when a fetched template differs from
the active one. The list in docs/zones.md left it out. Found in the
angular#3835 review.

Refs angular#3829

* docs: say which wrapped calls do not hold the app unstable

docs/zones.md says callback APIs hold the app unstable until an initial
value, so a server render waits for data. #3827 makes a set of calls
exceptions because their first callback may never come. Waiting on a
callback that never comes would keep the app from ever becoming stable.

List those calls in docs/zones.md, and point at onValue, object, list,
listVal and fromRef with the value event as the calls that still make a
server render wait.

In docs/database.md, say the same under stateChanges, auditTrail and
fromRef.

Refs #3826

* docs: describe firebase 13 support in the v22 upgrade guide

#3831 lets AngularFire 22 accept firebase 12 or 13, and the ng update
migration now writes the range of the firebase major already installed.
The upgrade guide still said the migration writes ^12.18.0 and quoted
peer warnings that name only that range.

State the supported range and what the migration writes, update the
Yarn 1 and pnpm 9/10 warnings to their current wording, and add a
section on moving to firebase 13: VertexAIBackend is removed and its
packages declare Node 24.12 or later.

Refs #3830

* docs: describe microtask delivery in the v22 upgrade guide

#3833 moves every Observable read from a setInterval timer to the next
microtask checkpoint. As a breaking change it needs a section in the
upgrade guide: which tests now see a value they used to wait for, the
setTimeout ordering flip, and the zoneless server render case for
hand-written TransferState entries.

Refs #3832

* docs: describe the callback pending-task change in the v22 upgrade guide

#3837 removes a callback read's pending task right after the callback
instead of one setTimeout(fn, 0) delay later. As a breaking change it
needs a section in the upgrade guide: what moves sooner, and which
tests notice.

Refs #3836

* docs: say a handler passed as an observer object is wrapped too

#3829 wraps a handler passed as an observer object, such as { next, error }, the way it wraps a function, so the injection context reaches both forms.

Refs #3828

* docs(compat): add a setup section in NgModule and standalone form

The compat API's setup steps left docs/install-and-setup.md when #3236
rewrote it for the modular API, and nothing replaced them. docs/compat.md
had no setup at all, the Realtime Database pages pointed at an
"Installation guide" that no longer covered compat, and no page showed
the standalone form. A standalone app with only the modular providers
then fails its first compat injection with NG0201 for
angularfire2.app.options (#3683).

The new section on docs/compat.md gives both forms, says when the modular
providers may stay, states the error the missing module produces, and
lists the compat module of each product. The twelve compat pages that had
an NgModule-only snippet or no setup at all now point at it.

Fixes #3683

* docs: say which package managers refuse an incompatible firebase

The v22 upgrade guide said an incompatible firebase is refused at
install time. Only npm refuses it, and only when package.json requests
the incompatible version. Yarn and pnpm install it with a warning.

* docs: say which Firestore functions are not zone wrapped

#3842 re-exports Firestore's query and reference builders, field
values, comparators and setLogLevel without the zone wrapper. In
docs/zones.md, add a paragraph listing them, change the switchMap
example to a read, since building the query no longer warns, and say
the Verbose log level covers only wrapped calls.

Refs #3842

* docs(auth): build the server app with initializeBrowserOrServerApp

The server-rendering guide's step 4 becomes the one call, the five
details become three, the App Check token gets a relay section, the
response gets a Cache-Control header, and the manual callback stays in
a "Building the app yourself" section that step 4 points at, for apps
that prefer it or whose AngularFire version has no such function. The
release modes say what a throwing ngOnDestroy does to a timed release.

* docs(auth): describe the sample as an example of the one-call server app

The sample app now has one provideFirebaseApp with
initializeBrowserOrServerApp in its shared app.config.ts (#3845), so
the sentence about its split client and server files no longer holds.

Refs #3843

* docs: say how to move from 22.0.0-rc.0 in the v22 upgrade guide

The guide covered upgrades from 21, a 21 release candidate and a 22
canary build, but not from the first 22 release candidate. ng add saves
a prerelease as an exact version, so an app on 22.0.0-rc.0 stays there
until ng update @angular/fire@next moves it. That command also runs
migration-v22 again, which reports "No changes made" for a firebase
entry already inside the supported range.

Refs #3834

* docs(auth): say which hooks stop a releaseAfterRender release

The caveat on releaseAfterRender said a throwing ngOnDestroy "stops that
teardown". It now says the release is a DestroyRef.onDestroy callback,
that Angular runs it after every service's and component's ngOnDestroy,
and that an ngOnDestroy method or an ApplicationRef.onDestroy listener
that throws keeps it from running. The default release, which does not
run during the injector's destroy, is unaffected either way.

A new paragraph says to call initializeBrowserOrServerApp in
app.config.ts rather than a route's providers: a route's child injector
is not destroyed with the request, so a release registered there never
runs.

Refs #3844

* docs(auth): say the default release still happens from a route's providers

Tyler asked on #3844 whether the default release, now tied to a root
service, releases a server app built in a lazy route's providers. It
does: the request's root injector is destroyed, the route's child
injector is not, so only a releaseAfterRender release registered there
is lost. Checked with a child environment injector that is never
destroyed, in both modes.

Refs #3844

* docs: add onConfigUpdate to the calls that do not hold the app unstable

#3829 set onConfigUpdate to blockUntilFirst: false in tools/build.ts,
because its observer runs only when a fetched template differs from
the active one. The list in docs/zones.md left it out. Found in the
#3835 review.

Refs #3829

* docs(auth): say a second provideFirebaseApp can render signed out

The bullet said a second registration makes a signed-in render fail
on a freshly started server. With more than one registration,
FirebaseApp resolves to the default app. Run on fresh servers, a
second plain initializeApp(config) registration creates that app on
the first request, so signed-in pages render signed out with no
error. Only when no registration creates the default app, as with
two initializeBrowserOrServerApp registrations, does the render
fail, and only until a signed-out request creates it. Found in the
#3835 review.

Refs #3844